home *** CD-ROM | disk | FTP | other *** search
/ Sprite 1984 - 1993 / Sprite 1984 - 1993.iso / src / cmds / gdb / foo / XGDB-README < prev    next >
Encoding:
Text File  |  1989-07-05  |  3.0 KB  |  58 lines
  1. XGDB is an attempt at a graphical interface from GDB to X windows.
  2. Its source code is in xgdb.c.  The decision of whether to include this
  3. file is made at *link time*; compile-time conditionals for xgdb are not
  4. allowed.  See the Makefile.
  5.  
  6. The current version does run with X11R2 but does not completely work.
  7. For one thing it encounters an apparent bug in the predefined widget
  8. used to display source files.  This bug (which I have reported) causes
  9. parts of the source-code display to appear blank.
  10.  
  11. But XGDB has bugs also.  I suspect that xgdb_display_source passes the
  12. wrong line-number arguments to that widget and it may work in an
  13. overcomplicated manner.  Also, at a deeper level, it does not handle
  14. X-events while either the inferior or a command is running.  This
  15. certainly means that the window won't refresh at such times.  It's
  16. possible that events also fail to be handled at other times, such as
  17. after a button has been clicked, and if so this would account for some
  18. of the failure to display the source text fully.
  19.  
  20. I think that someone who really understands the X toolkit ought to write
  21. something which will handle events asynchronously.
  22.  
  23. The user interface currently implemented is not very convenient to
  24. use.  For example, it is necessary to move the mouse back and forth
  25. often between the XGDB window and the window where XGDB's text I/O is
  26. done.  XGDB should arrange to receive keyboard input via the XGDB
  27. window so the mouse can be left there all the time.  These chars may
  28. need to be echoed explicitly and stuffed into the keyboard buffer so
  29. they intermix properly with those typed in the text I/O window.
  30.  
  31. Is it worth while to have several buttons that simply use the
  32. selection as keyboard input with a few extra characters before and
  33. after?  Perhaps it would be better to have just one button (or a mouse
  34. click) to use the selection as text input, since this would work in
  35. any GDB command.  You would first type the command yourself, then use
  36. the selection as input, then type RET yourself.  If this is done with
  37. a mouse click, and if keyboard input is allowed through the XGDB
  38. window, then all this can be done with no extra mouse motion.
  39.  
  40. There needs to be a command to find out the line number of the
  41. selected line (or it should be displayed all the time); otherwise how
  42. do you use the "jump" command, or go to the editor and find that line
  43. easily?  Alternatively there should be buttons for these two things.
  44.  
  45. Some of the buttons' meanings aren't evident.  For example, how does
  46. "Brk in" differ from "Brk at"?  What is "print *"?  I intuitively
  47. expected to click on a button and then select what it should apply to,
  48. and I was surprised to find that one must do it in the other order.
  49. There should be a "Help" button which displays a screen which explains
  50. all the features of the graphical interface, and perhaps an "Info"
  51. button which runs the info program to display the on-line GDB manual.
  52.  
  53. I would suggest that someone look at other graphical debuggers
  54. (including Sun's dbxtool) and consider how to change the interface to
  55. be easier to use in practice.
  56.  
  57.  -- RMS
  58.